|
|
|
|
|
|
|
Thus, throughout the remainder of this chapter, you can substitute business rule terminology with domain rule terminology if that helps. |
|
|
|
|
|
|
|
|
Understanding the Purpose of This Subsystem |
|
|
|
|
|
|
|
|
The Business Rules Subsystem enforces the policy of the user with respect to the user's organizational goals. The business classes and components that make up this subsystem have the main goal of providing one or more solutions to one or more organizational problems. For simpler applications, this subsystem can be implemented with only one class residing on the client machine. For more complex applications involving a number of groups of users within an organization, business classes can reside on any number of distributed computers. For instance, for a multinational banking corporation using a reasonable distributed application, classes that enforce the rules for clearing checks can reside on the workgroup servers for those groups that handle automated clearinghouse operations. |
|
|
|
|
|
|
|
|
To build a sound, reusable subsystem of business classes, especially in a distributed architecture such as is typical in large, modern organizations, takes considerable time. In fact, don't worry yourself with designing perfect business classes the first time around. It may take as little as a couple of projects over a year or two to as many as three to five years to get a reasonable return on investment, although you can certainly deploy business objects as soon as you have them designed, tested, and implemented. During the first few iterations of your applications, expect a number of increments to be necessary for developing business classes. After the entire project is complete, your application will evolve with maintenance and cyclical requests for new features to be added. Each evolutionary cycle after the final project iteration release is popularly known as a version change, where the version number is incremented. |
|
|
|
|
|
|
|
|
In more advanced issues, developing business classes with relational databases as part of the architecture of your environment can be tricky. Object databases such as ObjectStore (which has an ActiveX component for Visual Basic developers) don't require a separation of data from the objects themselves. However, relational databases, which still dominate the information storage and retrieval market, do require data disassembly. The problem then becomes how to effectively get the data out of business classes and into relational databases without compromising encapsulation rules. The bulk of the answer lies in design patterns. The lesson for Day 19, The Database Access Subsystem, introduces you to some patterns/mechanisms for handling data in business classes using Visual Basic. |
|
|
|
|
|